Method and device for generating a data stream and method and device for playing back a data stream

ABSTRACT

In a method for generating a second data stream from a first data stream, which comprises a first header and a first payload data block with payload data, the first header is initially extracted from the first data stream. Subsequently the second header for the second data stream is generated. Then, at least a part of the first header is entered into the second header, the part of the first header including information, which allows conclusions as to the origin of the payload data. Finally, the second payload data block is generated, which comprises the same payload data, so as to obtain the complete second data stream. The method according to the invention enables device-specific encrypting of payload data, a flexible, device-specific “copy” for other devices of a user and, in particular, complete documentation of the origin of the present copy, such that effective copyright protection may be realized.

FIELD OF THE INVENTION

The present invention relates to the encryption or decryption of payloaddata, like e.g. audio and/or video data and especially to audio and/orvideo data present in the form of a data stream comprising a header anda payload data block.

BACKGROUND OF THE INVENTION AND PRIOR ART

With the occurrence of telecommunication networks and in particular dueto the huge spreading of multimedia data-capable personal computers and,most recently, of so-called solid state players, a need has arisen tomarket digital multimedia data, such as digital audio data and/ordigital video data, commercially. Telecommunication networks for examplecan be analog telephone lines, digital telephone lines, such as ISDN, orthe Internet. Among the commercial providers of multimedia productsthere is a need to sell or lend multimedia data, wherein it should bepossible for a costumer to be able to select a certain productindividually at any time from a certain catalogue, this product then ofcourse being only allowed to be used by the costumer who has paid forit.

Unlike well-known encrypted television programs, such as the televisionchannel Premiere, in which the emitted data is encrypted in the same wayfor all users who have acquired a suitable decryption device by paying acertain charge, the present invention is to provide methods and devicesenabling an individual, customer-selective and safe encryption anddecryption of multimedia data. Unlike the television channels mentionedabove which give a fixed program all of which the user has to decidefor, the methods and devices of the present invention enable a maximumfreedom of selection for the user, which means that the user has only topay for those products he or she actually wants to use.

DE 196 25 635 C1 describes methods and devices for encrypting anddecrypting multimedia data, the multimedia data being present in theform of an encrypted multimedia file comprising a destination data blockand a payload data block. Parts of the destination data block and atleast some parts of the payload data block are encrypted by means ofdifferent keys, especially symmetrical encryption methods being used.

Further, in the method for encrypting or decrypting multimedia datadescribed in DE 196 256 35 C1 a user index is entered into adetermination data block of a bitstream with encrypted multimedia datathat identifies the user authorized to use an encrypted multimedia datastream. If this user index identifies merely one person, this method isonly safe against unauthorized copying if that person who has purchasedan encrypted multimedia data stream acts correctly and legally. Thiscan, however, not always be guaranteed. If the person who has purchasedan encrypted multimedia data stream legally carries out copying, it willnot be possible to see from a copy who has copied it. The origin of thecopy can therefore not be tracked down anymore which will open the wayfor violations of copyrights, incorrect behaviour assumed.

However, if the user index does, not only identify the user as a personbut a specific player of a user, like e.g. the PC of the user, a safetyis achieved in such a way that the user can play the encryptedmultimedia data stream only on the player identified by the user indexregardless whether the user behaves legally or illegally.

However, the problem with this solution is the fact that it is notflexible, i.e. it dictates the user where he has to play the purchasedmultimedia data stream due to the copyright protection. There is not alot of imagination needed to predict that such system will only findlittle acceptance at the market especially when thinking about the factthat a number of players exist in a normal household. Such players caninclude for example a personal computer, a laptop, a hifi system, a carhifi system, a video recorder, a solid state player, etc.

SUMMARY OF THE INVENTION

Therefore, it is the object of the present invention to provide aflexible concept for selectively providing multimedia data that on theone hand finds acceptance at the market and at the other hand takescopyright aspects into consideration.

In accordance with a first aspect of the present invention, this objectis achieved by a method for generating a second data stream from a firstdata stream which comprises a first header and a first payload datablock with payload data, the method comprising the following steps:extracting the first header from the first data stream; generating asecond header for the second data stream; entering at least a part ofthe first header into the second header, the part of the first headerincluding information which allows conclusions as to the origin of thepayload data; and generating a second payload data block having the samepayload data as the payload data block of the first data stream, so asto obtain the second data stream.

In accordance with a second aspect of the present invention, this objectis achieved by a method for playing a second data stream which comprisesa second header and a second payload data block and has been generateddue to a first data stream which comprises a first header and a firstpayload data block, wherein at least a part of the first header whichcomprises information regarding the origin of the first data stream, iscontained in the second header, the method comprising the followingsteps: extracting the part of the first header from the second header;verifying the origin of the second data stream using the part of thefirst header which comprises information regarding the origin of thefirst data stream; and in case of a positive result of the verifyingstep, playing the second data stream.

In accordance with a third aspect of the present invention, this objectis achieved by an apparatus for generating a second data stream from afirst data stream which comprises a first header and a first payloaddata block with payload data, the apparatus comprising the following:means for extracting the first header from the first data stream; meansfor generating a second header for the second data stream; means forentering at least a part of the first header into the second header, thepart of the first header including information which allow conclusionsas to the origin of the payload data; and means for generating a secondpayload data block which comprises the same payload data as the payloaddata block of the first data stream, so as to obtain the second datastream.

In accordance with a fourth aspect of the present invention, this objectis achieved by an apparatus for playing a second data stream whichcomprises a second header and a second payload data block and has beengenerated due to a first data stream which comprises a first header anda first payload data block, at least a part of the first header, whichcomprises information regarding the origin of the first data stream,being contained in the second header, the apparatus comprising thefollowing: means for extracting the part of the first header from thesecond header; means for verifying the origin of the second data streamusing the part of the first header which comprises information regardingthe origin of the first data stream; and means for playing the seconddata stream, which responds to the means for verifying, so as to playthe second data stream only if the means for verifying provide apositive result.

The present invention is based on the knowledge that music piracy canonly be limited by using a device-specific identification of payloaddata streams. This means that a payload data piece that has beenprocessed in the form of a payload data stream is not licensedperson-specific but device-specific. In order for such a system to findacceptance at the market the situation has to be taken into account thata person usually has several players and that a person wants to have afree choice on which player she/he wants to play the purchasedmultimedia piece.

It is pointed out at this stage that payload data in general includesmultimedia data that is audio data, video data or a combination of audiodata and video data, but also text data. For practical reasons thesubject matter of the present invention will be disclosed usingmultimedia data. It is however clear that all the payload data for whichthere is a demand to follow up their origin can be processed by thedevices and methods according to the invention.

However, to prevent the way from being opened again for unlimitedcopying, a “copy” of the multimedia data stream has to be carried outdevice-specific for another device of a user as well. At the same timeit is absolutely significant that the origin of each copy of amultimedia piece can be tracked down, i.e. it should always be possibleto ascertain without doubt who has created a multimedia piece (author,composer), who has put it into circulation (provider, distributor,supplier), who has made an intermediate copy, and who has possibly madea further intermediate copy, etc. Only when the origin is known a userof a multimedia piece can prove without doubt that he uses themultimedia piece legally, or only then an illegal user can be foundguilty without doubt.

Furthermore it is possible to carry out the binding of the multimediadata not to one player directly, but to bind the data to a “Smart Card”.Thereby identical multimedia data streams can be maintained on variousdevices, but can only be used on the respective device where the SmartCard is inserted at that time.

Therefore, according to the present invention a second data stream isgenerated from a first data stream comprising a first payload data blockwith multimedia data, that also comprises a first header and a firstpayload data block with multimedia data, a second data stream isgenerated that also comprises again a header and a payload data block.However, in this second header, i.e. the header of the second datastream according to the present invention at least those parts of thefirst header, i.e. the header of the first data stream allowingconclusions as to the origin of the multimedia data are included. Thesecond payload data block comprises the same multimedia data as thefirst payload data block, i.e. the payload data block of the first datastream.

The header of the second data stream can essentially have the sameformat as the header of the first data stream. However, it includesBesides the usual header information comprises additionally at least theinformation from the first header allowing conclusions as to the originof the multimedia data.

Essentially, in a preferred embodiment of the present invention, thewhole first header is entered into the second header. In order toprotect the second header comprising the first header from manipulationit can additionally be provided with a digital signature that is derivedfrom the data of the second (current) header and above that from thedata of the first (old) header. In a preferred embodiment of the presentinvention, data from the first header allowing conclusions as to theorigin of the multimedia data comprise a supplier identification, i.e.an identification of the supplier of the first data stream that couldfor example be the Deutsche Telekom (German telecommunications company),as well as author information allowing conclusions as to the author orcomposer, as well as a user identification, i.e. an identification ofthe device for which the data stream has originally been licensed.

It is a specific advantage of the inventive concept that it can becarried out as often as desired what leads to a multiply recursiveheader structure since a third data stream that comprises a third headerand a third payload data block again comprises origin information of thesecond header in its header. This origin information is on the one handthe origin information of the first header and on the other hand theorigin information of the second header. Analogous to the origininformation of the first header the origin information of the secondheader is for example an identification of the device the piece wasoriginally licensed for by the original supplier and an identificationof the device a “copy” was made for, for example an identification of acar hifi system.

Here, it will be especially noted that the author information of thefirst header is also present in the header of the third data stream.Thus, the inventive concept is in conformity with statutory regulationsregarding any program or any apparatus removing author information asillegal. Such statutory regulations have already become national law inthe United States and it might only be a question of time when theseregulations will be nationalized Europe wide.

In a preferred embodiment of the present invention the part of an oldheader taken over into the new header contains only licensinginformation referring to the manner how a licensed multimedia piece maybe used, i.e. how often it may be played and how often it may be copiedor whether a copy of a copy is legal or not.

The payload data block can of course be encrypted symmetrically, whilethe key of the symmetrical encrypting method is encryptedasymmetrically. In this case an apparatus for generating the second datastream will carry out a complete decryption from the first data streamand subsequently a complete new encryption.

Thus, the inventive concept allows full protection of a multimedia piecein a way from the author or composer via an arbitrary number of copiesto an end user. Above that, the origin of a current copy can be trackeddown unbrokenly at any time of a copy or distribution chain whereby thenumber of copies or distribution processes is arbitrary. Additionally,author information is considered any time whereby copyright protectionis satisfied. Finally, the inventive concept can be implementedefficiently and flexible such that it is also suitable for inexpensiveplayers with limited memory and processor resources, that it is easy tohandle, and that modern client demands for high flexibility are fullyconsidered.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a multimedia data stream, which can be produced accordingto the present invention;

FIG. 2 shows a detailed illustration of the header and the payload datablock of the encrypted multimedia data stream;

FIG. 3 shows a selection of certain entries into the individual subblocks of the header block;

FIG. 4 a schematic illustration of a distribution scenario;

FIG. 5 a schematic view of a data stream with recursive headerstructure;

FIG. 6 a flow chart of a method for generating a second data stream froma first data stream according to the present invention; and

FIG. 7 a method for playing a second data stream generated based on afirst data stream according to the present invention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

FIG. 1 shows an encrypted multimedia data stream 10 comprising a header12 and a payload data block 14 that is a block containing encryptedmultimedia data. The payload data block 14 includes encrypted sections16 and unencrypted sections 18 between the encrypted sections 16. Inaddition a multimedia data stream, which can be produced according tothe present invention, includes a further unencrypted section 20following the header 12 and being arranged in front of an encryptedsection 16.

Usually the multimedia data to be encrypted is encoded in any way, suchas according to a MPEG standard, such as MPEG-2 AAC, MPEG-4 audio orMPEG Layer-3. It is thus sufficient to encrypt certain sections of themultimedia data to be encrypted. This leads to an essentially decreasedprocessing expenditure both at the provider who encrypts the data and atthe customer who in turn has to decrypt the data. Furthermore, thepleasure of hearing and seeing respectively of a user who only uses theunencrypted multimedia data is seriously impaired by the constantlyoccurring encrypted blocks, when the multimedia data is only encryptedpartly.

Although FIG. 1 shows an encrypted multimedia data stream in which theheader 12 is arranged at the beginning of the encrypted multimedia datastream this arrangement of the header and the payload data block is notto refer to the transmission of the encrypted multimedia data stream.The term “header” is only meant to express that a decryption devicewhich is to decrypt the encrypted multimedia data stream at firstrequires at least parts of the header before the multimedia data itselfcan be decrypted. Depending on the transmission medium the header mayalso be arranged at some place in the payload data block or be receivedafter certain parts of the payload data block when for example apacket-oriented transmission of the multimedia data stream is thoughtof, in which different packets, one of which may contain the header andanother one a part of the payload data block, are transmitted viadifferent physical transmission ways in such a way that the order ofreceipt does not have to correspond to the order of sending. However, inthis case a decryption device has to be able to save the packetsreceived and to order them again in such a way that information isextracted from the header to begin the decryption. The encryptedmultimedia data stream may further be present in the form of a file oralso in the form of an actual data stream, when for example a lifetransmission of a multimedia event is thought of. This application willespecially occur with digital user-selective broadcasting.

The length of an encrypted section 16 is represented by a value amount22 while the spacing in the encrypted multimedia data stream from thebeginning of an encrypted section 16 to the beginning of the nextencrypted section 16 is referred to as step 24. The length of thefurther encrypted section 20 is given by a value first step 26.

These values 22, 24 and 26 are obviously required for a correctdecrypting of the multimedia data in a decryption device. This is whythey have to be entered into the header 12 as will be explained later.

FIG. 2 shows a more detailed illustration of the encrypted multimediadata stream 10 consisting of the header 12 and the payload data block14. The header 12 is divided into several sub blocks that will beexplained especially referring to FIG. 3. It is pointed out that thenumber and the function of the sub blocks can be extended at will. Thus,in FIG. 2 some sub blocks of the header 12 are illustrated in an onlyexemplary way. The header includes as it is shown in FIG. 2 a so-calledcrypt-block 28 comprising, in general terms, relevant information forencrypting the multimedia data. In addition the header 12 includes aso-called license block 30 comprising data referring to how a user canor is allowed to use the encrypted multimedia data stream. The header 12further includes a payload data info block 32 which can includeinformation concerning the payload data block 14 and as well as generalinformation about the header 12 itself. Furthermore the header 12 maycomprise an old header block 34 enabling a so-called recursive headerstructure. This block makes it possible for the user who, apart from adecryption device is also in the possession of an encryption device toreformat an encrypted multimedia data stream for other replayinstruments in his possession without losing or modifying the originalheader information provided by the distributor. Depending on theapplication further sub blocks, such as an IP information block(IP=intellectual property) according to ISO/IEC 14496-1, MPEG-4,Systems, 1998, containing copyright information, can be added to theheader 12.

As it is the standard in the art, an internal block structure can beallocated to each block, this structure at first requesting a blockidentificator and including the length of the sub block and at lastgiving the block payload data itself. Thus, the encrypted multimediadata stream, and in particular the header of the encrypted multimediadata stream, is given an increased flexibility in such a way that it canreact to new requirements in such a way that additional sub blocks maybe added or existing sub blocks may be omitted.

FIG. 3 gives an overview of the block payload data of the individual subblocks shown in FIG. 2.

At the beginning the crypt block 28 is explained. It contains an entryfor a multimedia data encryption algorithm 40 identifying thesymmetrical encryption algorithm used in the preferred embodiment, whichhas been used when encrypting the multimedia data. The entry 40 can bean index for a table in such a way that, after reading the entry 40, adecryption device is capable of selecting this encryption algorithm theencryption device has used from a plurality of encryption algorithms.The crypt block 28 further includes the entry first step 26, the entrystep 24 and the entry amount 22, which has already been illustrated inconnection with FIG. 1. These entries in the header enable a decryptiondevice to subdivide an encrypted multimedia data stream accordingly tobe able to carry out a correct decryption.

The crypt block 28 further contains an entry for the distributor orprovider or supplier 42, the entry being a code for the distributor whohas produced the encrypted multimedia data stream. An entry user 44identifies the user who has obtained the encrypted multimedia datastream in some way from the distributor who is identified by the entry42. According to the invention it is preferred not to use aperson-related user identification since this would open the way forillegal copies. Instead it is preferred to carry out the useridentification device specific. The entry user would then for examplecomprise the serial number of a PC, a laptop, a car hifi system, a homestereo system, smart card etc. that authorizes playing only on a certaindevice. For further increase of flexibility and/or safety a certainidentification like for example a logic link of the hard disk size withthe processor number etc. for the example of a PC can be applied insteadof a serial number that looks different for every producer but might bychance be identical.

An entry 46 contains an output value that will be discussed in detaillater. This output value in general represents an encrypted version ofthe multimedia data key which, in connection with the multimedia dataencryption algorithm identified by the entry 40, is required to decryptthe encrypted multimedia data (sections 16 in FIG. 1) present in thepayload data block 14 correctly. In order to achieve a sufficientflexibility for future applications, the two entries output value length48 and output value mask 50 are further provided. The entry output valuelength 48 illustrates the actual length of the output value 46. Toachieve a flexible header format more bytes are however provided in theheader format, for the output value than an output value actuallycomprises. The output value mask 50 thus illustrates how a shorteroutput value is distributed in a way on a longer output value place. Ifthe output value length is for example half as big as the spaceavailable for the output value, the output value mask could be formed insuch a way that the first half of the output value mask is set while thesecond half is masked. In this case the output value would simply beentered into the space provided for the header by the syntax and occupythe first half while the other half would be ignored due to the outputvalue mask 50.

Now the license block 30 of the header 12 FIG. 2 will be explained. Thelicense block includes an bit mask 52. This entry can comprise certainspecific information for replaying or for the general way of using theencrypted multimedia data. With this entry a decryption device couldespecially be told whether the payload data can be replayed locally ornot. In addition at this point it may be signalled whether the challengeresponse method has been used for the encryption, this method beingdescribed in the already mentioned German patent DE 196 25 635 C1 andenabling an efficient data base access.

An entry expiration date 54 indicates the point in time at which thepermission to decrypt the encrypted multimedia data stream expires. Adecryption device will in this case check the entry expiration date 54and compare it to a build-in time measuring device in order not to carryout a decryption of the encrypted multimedia data stream if theexpiration date has been exceeded. This makes it possible for theprovider to make encrypted multimedia data available for a limitedamount of time, which has the advantage of a much more flexible handlingand price setting. This flexibility is further supported by an entrystarting date 56 in which it is specified from which point on anencrypted multimedia file is allowed to be decrypted. An encryptiondevice will compare the entry starting date with its built-in watch toonly carry out a decryption of the encrypted multimedia data when thecurrent point in time is later than the starting date 56.

The entry allowed replay number 58 indicates how often the encryptedmultimedia data stream can be decrypted, that is replayed. This furtherincreases the flexibility of the provider in such a way that it forexample only allows a certain number of replays compared to a certainsum which is smaller than a sum which would arise for the unlimitedusage of the encrypted multimedia data stream.

For verifying and supporting respectively the entry allowed replaynumber 58 the license block 30 further includes an entry actual replaynumber 60 which could be incremented by one for example after eachdecryption of the encrypted multimedia data stream. A decryption devicewill thus always check whether the entry actual replay number is smallerthan the entry allowed replay number 58. If this is the case, adecryption of the multimedia data is carried out. If this is not thecase, a decryption is no longer carried out.

Analog to the entries 58 and 60 entries allowed copy numbers 62 andactual copy number 64 are implemented. By means of the two entries 62and 64 it is made sure that a user of the multimedia data only copiesthem as often as he or she is allowed to do so by the provider or asoften as he or she has paid for when purchasing the multimedia data. Bythe entries 58 to 64 a more effective copyright protection is assured, aselection between private users and industrial users being attainablefor example by setting the entries allowed replay number 58 and allowedcopy numbers 62 to a smaller value.

The licensing could for example be designed in such a way that a certainnumber of copies (entry 62) of the original are allowed while copies ofa copy are not allowed. The header of a copy would then, unlike theheader of the original, have zero as the entry allowed copy number insuch a way that a proper encryption/decryption device can no longer copythis copy.

In the example for a multimedia data protection protocol (MMP) shownhere the header 12 further contains a payload data information block 32having in this case only two block payload data entries 66 and 68, theentry 66 containing a hash sum on the total header, while the entry 68identifies the type of hash algorithm having been used for forming thehash sum on the total header.

Hash algorithms are known in the art and can be used to form a digitalsignature of a data amount such that also a small change of data in adata amount leads to a change of the digital signature whereby theauthenticity of data and especially of the (non encrypted) header can bechecked in an easy and efficient way.

A preferred method for generating a digital signature is to form a hashsum on the whole header and to encrypt or decrypt it asymmetrically inorder to obtain the entry 66. Specifically, the supplier would decryptthe hash sum of the whole header with his private key. However, theencryption apparatus at the customer would form the hash sum on thewhole (eventually illegally modified) header itself and above thatdecrypt the entry 66 with the public key of the asymmetrical encryptionmethod and then compare the two results. If they match, the playingprocess will be started. If they don't match, nodecrypting/decoding/playing is possible.

In this context reference is made for example to “Applied Cryptography”,Second Edition, John Wiley & Sons, Inc. by Bruce Schneider (ISBN 0417-11709-9) including a detailed illustration of symmetrical encryptionalgorithms, asymmetrical encryption algorithms and hash algorithms.

The header 12 finally includes the old header block 34, which, alongwith the synchronizing information, which is not shown in FIG. 3,comprises the entry old header 70. In the entry old header 70 the oldheader can be maintained by the provider if a user performs anencryption himself and thus produces a new header 12, in order not tolose essential information the provider has entered into the header.

For this purpose other information 74 (IP information block 72) couldfor example count prior user information and distributor informationwhich enables tracing back of a multimedia file which for example hasbeen decrypted and encrypted several times by different instruments tothe original provider transparently, the other information 74 beingmaintained. It is thus possible to check at any point whether anencrypted multimedia file has been acquired legally or illegally.

FIG. 4 shows a schematic block diagram of a scenario wherein theinventive concept can be applied in an advantageous way. An author orcomposer 100 has created a multimedia piece, for example a text, a pieceof music, a film or a picture. He delivers this work, in this inventiongenerally referred to as multimedia piece, to a supplier 102 ofmultimedia data. It is especially pointed out here that the expression“multimedia data” in the sense of the present invention comprises audiodata, video data or a combination of audio and video data.

The supplier ensures that the multimedia piece of the author/composer100 is put in circulation by encoding it for example according to themethod MPEG layer 3 (MP3). In order to achieve a customer selectiveproviding for use of the encoded multimedia piece the supplier 102 willbring the encoded multimedia piece into a first data stream comprising aheader and payload data block. A data stream as it might be used isillustrated in FIG. 3.

In this connection it should be especially pointed to the IP informationblock 72 comprising author information 74 as payload data identifyingthe author/composer or in general artist. The IP information block couldfor example be carried out according to ISO/IEC 14496-1 MPEG-4 systems,1998. It could especially comprise the name of theauthor/composer/artist or also the ISBN number (ISBN=internationalstandard book number), the ISRC code (ISRC=international standardrecording code), the ISAN number (ISAN=international standardaudiovisual number), the ISMN number (ISMN=international standard musicnumber), etc. Such meta information will allow a unique identificationof the author of the multimedia piece such that by adding these metainformation to the payload data the enforcement of copyrights will bemuch easier.

The supplier of multimedia data 102 generates a first data streamcomprising a first header and a first payload data block. All the dataillustrated in FIG. 3 can be included in the header, wherein the authorinformation (entry 74), the distributor identification (entry 42) andthe user identification (entry 44) should be especially noted. While theauthor information (entry 74) represents the origin of the multimediapiece in general, the distributor identification (42) uniquely definesthe origin of the first data stream while the user identificationdefines the “destination” of the first data stream, i.e. the device thatis allowed to use the data stream and that has also paid for it, wherebyon the one hand the service of the supplier 102 of multimedia data ispaid and on the other hand royalties to the author/composer 100 canflow. In the first header of the first data stream a receiver-PC 104could for example be identified by the user identification 44. The firstdata stream can now on the one hand be played on the receiver-PC 104,however, according to the invention, the receiver-PC is defined in sucha way that it can also generate a “copy” of the first data steam inorder to generate one or several second data streams comprising in theirheader the user identification 44 of a car hifi system 106 a, a homehifi system 106 b, a solid state player 106 c, etc.

Every second header will essentially comprise the same payload datablock, the header of every second data stream, i.e. the second header,will however be different regarding the user identification 44. However,according to the invention, every second header will compriseinformation allowing conclusions as to the origin of the respectivesecond data stream. This information can comprise author information, anidentification for the receiver-PC 104 and an identification for thesupplier 102 of the first data stream. Preferably, the second headeradditionally comprises licence information referring to the fact howoften the multimedia piece may be played or how often it may be copied.It can especially happen that for example five copies are allowed but nocopy of the copy is allowed. In the entry allowed copy number 62 of thefirst header there would for example be five. In the entry allowed copynumber of the second header however, there would be zero. Even when thecar hifi system 106 a, the home hifi system 106 b or the solid stateplayer 106 c were designed in such a way that it can carry out adecryption or an encryption by itself, i.e. like the receiver-PC 104,still no further copy would be produced, i.e. no third data stream,since the entry 62 in the second header of the second data stream is setto zero. If this were not the case and if the copy of a copy wereallowed the devices 106 a to 106 c could again create third data streamsbut would comprise origin information of the respective second datastream and naturally of the respective first data stream.

This results in a recursive header structure shown schematically in FIG.5 that can principally be repeated arbitrarily. FIG. 5 shows an nth datastream 110 comprising an nth header 112 and an nth payload data block114. The nth header 112 again comprises a (n−1)th header that againcomprises a (n-2)th header, etc.

Preferably, the supplier of multimedia data 102 (FIG. 4) encrypts themultimedia data in the first payload data block at least in parts.Preferably, a symmetrical encrypting method for encrypting themultimedia data is used, wherein the key of the symmetrical encryptingmethod is again encrypted asymmetrically. The asymmetric key encryptedwith the private key of the supplier 102 for the symmetrical encryptingmethod is the output value 46 (FIG. 3). The receiver-PC 104 willtherefore need the respective public key of the supplier 102 ofmultimedia data in order to decrypt the output value 46 again, in orderto obtain the key for the symmetrical decrypting method that thesupplier 102 of multimedia data has used as well. The receiver-PC 104 isnow enabled to play the first data stream. If the first data stream isencoded the receiver-PC 104 carries out a decoding prior to playing. Thesequence will therefore be: decrypting, decoding, and playing.

However, the receiver-PC should also be able to generate a second datastream for a specific additional player 106 a to 106 c. In this case thereceiver-PC 104 can be configured for encrypting the multimedia datathat are decrypted, wherein a symmetrical encrypting method is preferreddue to speed aspects. The receiver-PC 104 will again asymmetricallyencrypt the key for the symmetrical encrypting method with its privatekey, provide the second header with its own identification asdistributor entry 42 and further provide the second header with theidentification for example of the car hifi system as user identification44. Further, the receiver-PC 104, will generate a different output valuethat will be entered into the entry 46 of the second header since thereceiver-PC has a different data key than the supplier 102 of multimediadata. Above that, the receiver-PC will update the licence-block of thesecond header as desired. However, according to the invention, it willpreferably write the whole first header into the entry old header 70 insuch a way that all information of the first header are maintained andespecially the origin information of the first data stream as it hasbeen described several times.

Neither the first, second or the nth header are encrypted themselves. Inorder to protect the respective headers from attacks after thecompletion e.g. of the second header a hash sum is formed on the headerfor example according to a hash algorithm identified in entry 68 (FIG.3). Preferably, this hash sum is not only formed by the blocks 28, 30,32, 72 of the second header but it also comprises the block for the oldheader 34. This hash sum can then be directly entered into the entry 66(FIG. 3). For the increase of safety it is however preferred to enter adigital signature for the hash sum of the second header. A digitalsignature of the hash sum on the second header could for example beagain formed with an asymmetrical encryption method in such a way thatthe receiver-PC 104 generating the second data stream encrypts the hashsum on the second header with its own private key and writes the resultinto the entry 66.

The home hifi system 106 b will now at first verify the second datastream by also forming a hash sum on the second header as it is suppliedto the home hifi system. Further, the home hifi system 106 b willdecrypt the entry 66 in the second header with the public key of thereceiver-PC 104 and compare the obtained result with the just calculatedhash sum. If both hash sums are the same it can be assumed that thesecond data stream has not been manipulated. If the two results differ,a legally implemented car hifi system will not continue playing since itcan be assumed that unallowed manipulations have been carried out eitherat the second header or in a way “belated” at the first header.

FIG. 6 shows a flow chart for the inventive method for generating asecond data stream from a first data stream that is carried out by thereceiver-PC 104 in order to “retag” the device specifically licensedfirst data stream to other devices (106 a to 106 c).

Basically, the receiver-PC 104 will at first extract the header from thefirst data stream (116). Above that, the receiver-PC 104 will generate asecond header for the second data stream (118) as far as possible. Thisheader generated as far as possible could comprise all information ofthe header shown in FIG. 3 (blocks 28, 30, 32, 34, 72), but not the oldheader block 34. This block will be described in a step 120, wherein atleast the origin information from the first header is entered into theentry 70. However, for safety reasons and also for implementationreasons it is preferred to enter not only the origin information fromthe first header but also all information from the first header into theentry 70 of the second header. This could lead to the fact that certaininformation exist twice, like e.g. the author information 74 as well asinformation from other blocks, for example first step 26, step 24,amount 22, etc. Already here it can be seen that by the fact that thereceiver-PC 104 generates a complete second header in step 118 it is notbound to the parameters of the supplier 102 of multimedia data. Forexample, a less expensive encrypting method could be applied in order toenable the second data stream to be encrypted with less effort again forexample by the solid state player 106 c that needs, as known, limitedmemory and processor resources in order to be offered inexpensively.Considering these aspects the payload data block of the second datastream might even not be encrypted anymore at all, if preferred.

Finally, the receiver-PC 104 generates a second payload data block forthe second data stream (122) in order to finally obtain the second datastream.

The flow chart in FIG. 7 describes in general a method for playing asecond data stream generated based on a first data stream, wherein thismethod could be carried out in one of the devices 106 a to 106 c. Ifbetween the supplier 102 of multimedia data and the receiver-PC 104 afurther intermediate distributor as for example a “retailer” ofmultimedia data is disposed whom the supplier 102 of multimedia data whowill then have a wholesaler function supplies, the inventive methodgenerally illustrated in FIG. 7 would already be carried out by thereceiver-PC 104.

Generally, the method for playing can be started with the step ofreading the second header of the second data stream (130). The device106 a will then for example extract the part of the first headercomprising origin information, i.e. the old header block 34 and read thepayload data of the entry 70 (132).

In order to prevent the playing of illegal pieces the origin of thesecond data stream is verified in step 134 using the origin informationin entry 70. Such a verification could for example consist of checkingwhether origin information is present in the second header at all (136).If it is found out in the verification 136 that no origin information ispresent in the second header at all, a legally driven playing apparatusaccording to the present invention will refuse playing and will stop theoperation (138). If it is found out in this simple form of verification136 that origin information is present and that it makes sense and is no“deception data” of some sort, the inventive playing apparatus willbegin or continue playing the second data stream (140).

A more expensive way of verification could be to test whether thesupplier identification 42 of the second header matches the useridentification 44 of the first header. In this case it would be provedwithout doubt that the copy present in the player comes from therespective home-PC. Any further verification techniques with more orless effort are considered.

In a preferred embodiment of the present invention it is preferred tocarry out the verification via a digital signature comprising both dataof the first header and data of the second header, as it has beendescribed in connection with FIG. 4. Further even more complicatedmethods can also be used for verification wherein however always theorigin of the present data stream is tested that can either be authorinformation or other respective supplier entries 42 or user entries 44of the individually embedded header of the generally spoken multiplyrecursive header structure that is illustrated in FIG. 5.

Besides the verification of the origin of the second data stream (step134 in FIG. 7) the player will preferable be implemented in such a waythat it processes also the licence block 30 and especially for exampleaccording to the entries 58 and 60 processes regarding to the authorizedor actual playing number in order to find out whether it may play a datastream. The player will of course use the other information of thesecond header in the described manner if the second data stream isencrypted in order to finally decrypt, decode and play the second datastream.

1. Method for generating a second data stream from a first data streamwhich comprises a first header and a first payload data block withpayload data, wherein the first header comprises a first supplieridentification for a supplier of the first data stream and a first useridentification for a receiver of the first data stream, the methodcomprising the following computer implemented steps: extracting thefirst header from the first data stream; generating a second header forthe second data stream, wherein the second header comprises a secondsupplier identification for a supplier of the second data stream and asecond user identification for a receiver of the second data stream;entering at least a part of the first header into the second header, thepart of the first header including information which allows conclusionsas to the origin of the payload data, wherein the information comprisesthe first supplier identification for the supplier of the first datastream, and the first user identification for the receiver of the firstdata stream; and generating a second payload data block having the samepayload data as the payload data block of the first data stream, so asto obtain the second data stream; wherein the payload data include audiodata, video data, a combination of audio data and video data, or textdata.
 2. Method as claimed in claim 1, wherein the information allowingconclusions as to the origin of the first data stream further includesauthor information, such as information on an author or a composer, anISRC number, an ISAN number or an ISMN number of the payload data of thefirst data stream.
 3. Method as claimed in claim 1, wherein the firstuser identification is device-specific, the method further comprisingthe step of receiving the first data stream by a player or by a smartcard indicated by the first user identification.
 4. Method as claimed inclaim 1, wherein the part of the first header which is entered into thesecond header further comprises licence data relating to the manner inwhich a receiver of the first data stream may use the same, the licencedata of the first header specifying the licence data of the secondheader.
 5. Method as claimed in claim 4, wherein the licence data of thefirst header specify that the first data stream may be copied a certainnumber of times, that no copy may be taken of a copy, and wherein thestep of generating the second header for the second data stream includesthe step of entering second licence information into the second headerof the second data stream, such that no more copies are allowed to betaken of the second data stream.
 6. Method as claimed in claim 1, whichfurther comprises the following step: issuing a digital signature forthe second header, including the part of the first header, and attachingthe digital signature to the second header.
 7. Method as claimed inclaim 6, wherein the issuing step further comprises the followingsubsteps: forming a hash sum over the second header, including the partof the first header, using a specified hash algorithm; and encryptingthe hash sum by means of an asymmetric encrypting method using a privatekey of the receiver of the first data stream.
 8. Method as claimed inclaim 1, wherein the payload data in the payload data block are at leastpartly encrypted and wherein encrypting information is contained in thefirst header, the step of generating the second header furthercomprising the following steps: decrypting the first payload data blockof the first data stream using the encrypting information in the firstheader, encrypting the decrypted payload data and entering correspondingencrypting information into the second header, the encryptinginformation of the first header also being entered into the secondheader.
 9. Method as claimed in claim 8, wherein the encrypted payloaddata in the first payload data block are encrypted symmetrically using akey and wherein the key is again encrypted asymmetrically using aprivate key, the decrypting step comprising the following steps:decrypting the encrypted key by means of the public key of the supplierso as to obtain the key for asymmetric decryption; encrypting a payloaddata key of the decrypted payload data using a private key of a receiverof the first data stream carrying out the method for generating a seconddata stream; and entering the asymmetrically encrypted payload data keyinto the second header.
 10. Method as claimed in claim 1, wherein in thestep of entering, the entire first header is entered into the secondheader.
 11. Method as claimed in claim 1, wherein the first headeritself comprises at least a part of a header of a data stream whichrelates to the origin of the first data stream, such that the enteringstep results in a multiple recursive header structure.
 12. Method forplaying a second data stream which comprises a second header and asecond payload data block and has been generated due to a first datastream which comprises a first header and a first payload data block,wherein at least a part of the first header which comprises informationregarding the origin of the first data stream, wherein the informationcomprises a first supplier identification for a supplier of the firstdata stream, and the first user identification for a receiver of thefirst data stream, is contained in the second header, wherein the secondheader comprises a second supplier identification for a supplier of thesecond data stream and a second user identification for a receiver ofthe second data stream, the method comprising the following computerimplemented steps: extracting the part of the first header from thesecond header; verifying the origin of the second data stream using thepart of the first header which comprises information regarding theorigin of the first data stream, wherein a positive result is obtainedif the second supplier identification matches the first useridentification, and wherein a negative result is obtained if the secondsupplier identification does not match the first user identification; incase of a positive result of the verifying step, playing the second datastream; and in case of a negative result of the verifying step, refusingto play the second data stream.
 13. Method as claimed in claim 12,wherein the second header of the second data stream has a digitalsignature attached to it which fits the part of the first header, andwherein the verifying step comprises the following substep: checking theauthenticity of the second header using the digital signature. 14.Method as claimed in claim 13, wherein the digital signature is theresult of an encryption of a hash sum of the second header, whichencryption has been carried out by means of a private key of theapparatus having generated the second data stream, the step of checkingthe authenticity comprising the following steps: decrypting the digitalsignature by a public key of the apparatus which has generated thesecond data stream, so as to obtain the hash sum of the second header;forming a hash sum of the present header; comparing the hash sums; incase of the hash sums matching, issuing a positive verification result.15. Method as claimed in claim 14, wherein the part of the first headerfurther comprises licence information regarding the manner in which thefirst data stream may be utilized, and wherein the second headercomprises licence data derived from the licence data of the firstheader, the method further comprising the following substeps: comparingthe licence data of the second header and the first header so as toevaluate the authenticity of the licence data of the second header; incase of questionable authenticity, blocking the playing of the seconddata stream.
 16. Apparatus for generating a second data stream from afirst data stream which comprises a first header and a first payloaddata block with payload data, wherein the first header comprises a firstsupplier identification for a supplier of the first data stream and afirst user identification for a receiver of the first data stream, theapparatus comprising the following: an extractor for extracting thefirst header from the first data stream; a second header generator forgenerating a second header for the second data stream, wherein thesecond header comprises a second supplier identification for a supplierof the second data stream and a second user identification for areceiver of the second data stream; a processor for entering at least apart of the first header into the second header, the part of the firstheader including information which allow conclusions as to the origin ofthe payload data, wherein the information comprises a first supplieridentification for a supplier of the first data stream, and the firstuser identification for a receiver of the first data stream; and asecond payload data block generator for generating a second payload datablock which comprises the same payload data as the payload data block ofthe first data stream, so as to obtain the second data stream. 17.Apparatus as claimed in claim 16, which is designed as a personalcomputer.
 18. Apparatus for playing a second data stream which comprisesa second header and a second payload data block and has been generateddue to a first data stream which comprises a first header and a firstpayload data block, at least a part of the first header, which comprisesinformation regarding the origin of the first data stream, wherein theinformation comprises a first supplier identification for a supplier ofthe first data stream, and the first user identification for a receiverof the first data stream being contained in the second header, whereinthe second header comprises a second supplier identification for asupplier of the second data stream and a second user identification fora receiver of the second data stream, the apparatus comprising thefollowing: an extractor for extracting the part of the first header fromthe second header; a verifier for verifying the origin of the seconddata stream using the part of the first header which comprisesinformation regarding the origin of the first data stream; and a playerfor playing the second data stream, which responds to the means forverifying, so as to play the second data stream only if the means forverifying provide a positive result, and to refuse playing the seconddata stream in the case of a negative result.
 19. Apparatus as claimedin claim 18, which is designed as a hifi system, as a car hifi system,as a portable multimedia player, as a computer or as a component of anyof the above-mentioned devices.